I'm actually not sure which variant I prefer.

✅ Deploy Preview for fakerjs ready!

Name	Link
🔨 Latest commit	fa8c91f
🔍 Latest deploy log	https://app.netlify.com/sites/fakerjs/deploys/6727544e4c713e0008b1a37d
😎 Deploy Preview	https://deploy-preview-3203.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.96%. Comparing base (18f14c8) to head (fa8c91f).
Report is 1 commits behind head on next.

@@            Coverage Diff             @@
##             next    #3203      +/-   ##
==========================================
- Coverage   99.96%   99.96%   -0.01%     
==========================================
  Files        2805     2805              
  Lines      217098   217098              
  Branches      971      966       -5     
==========================================
- Hits       217025   217013      -12     
- Misses         73       85      +12     

The alternative solution would actually "catch" accidental null inputs from our users:

I compressed the signature for simplicitiy sake:

sentence({
    min: number;
    max: number;
} = { min: 3, max: 10 }): string {
    const sentence = this.words(wordCount);
    // ...
}
sentence(); // works
sentence(undefined); // works
sentence(null); // errors!!!

sentence({
    min: number;
    max: number;
}): string {
    const sentence = this.words(wordCount ?? { min: 3, max: 10 });
    // ...
}
sentence(); // works
sentence(undefined); // works
sentence(null); // works

I jsut wanted to point that out.

You could say the same for other methods such as faker.number.int(null).
That's why we recommend strict mode.

Also AFAICT:

faker.lorem.sentence(null)
"Tenax vilitas harum."

I also don't have a strong preference. Just want to point out according to #3215 (comment) the faker.lorem.* methods are some of the most heavily used in Faker so we should be very careful not to accidentally change runtime behavior even if it's a subtle change for a edge case.